Autonomous Underwater Vehicles : AUV Build and Test Server Setup

This page last changed on Mar 25, 2009 by tm.

AUV Build and Test Server Setup

Debian Version

Debian Etch 4.0 Release 3 has been used for auv-linux, Etch 4.0 Release 6 is currently available. It is recommended to take the bug fixes that come

Note: Debian 5.0 (lenny) was released on Feb. 14^th. It contains GNU Compiler Collection 4.3.2, Linux kernel version 2.6.26. This version will NOT initially be used until Debian 4.0 is proven.

Debian 4.0 and AUV-Linux install instructions AUV Debian4 Linux and auv-pkgs Install, build

Build Server Setup

Note: There was no easy access to a DVD burner for full Debian installer so the process used the net install DVD used in previous AUV-Linux effort. Installed Desktop+Standard configuration, root (autonomy) and dorado1 (dorado1) accounts. Machine name is betta.shore.mbari.org.

Required Packages

apt-get install jam
apt-get install swig (libSystem fails to build)
apt-get install libboost-regex-dev

Java Installation

Create a java installation specific to the auv-linux and auv-autonomy development and decouple from the debian system java:

Install in a named directory in opt, example: /opt/jdk_1.6u12

In the dorado1 user profile, set the environment variable to /opt/jdk_1.6u12 - explicit references is better for config management.

Download jdk to /home/dorado1/tools/java

At the terminal: Type:
su
Enter the root password.
Change to the directory in which you want to install and copy the java installer bin to this directory. Type:
cd /opt
cp /home/dorado1/tools/java/jdk-6u12-linux.i586.bin .
Change the permission of the bin file to be executable. Type:
chmod a+x jdk-6u12-linux-i586.bin
Verify that you have permission to execute the file. Type:
ls -l
Start the installation process.Type:

./jdk-6u12-linux-i586.bin

Press the spacebar to display the next page. At the end, enter yes. For this procedure the jdk is installed in the /opt/jdk1.6.0_12 directory. When the installation has completed, you will see the word Done.

Autonomy Software checkout:

cd /home/dorado1/prj

svn co svn+ssh://kahuna.shore.mbari.org/svn/repos/TREX/trunk TREX

copy Europa from threadfish (Yikes! NASA version is moving ahead of TREX)

Build failed (jam in TREX) due to missing boost regex loadable module. To resolve this, a debian package was installed (developer version) which is a bit of a sledge hammer. Need to determine of this is a standard component of the OS or a developer package specific to TREX (judged it to be an OS component)

apt-get install libboost-regex-dev

Build failed due to libSystem.so missing

Fix: add $PLASMA_HOME/lib to LD_LIBRARY_PATH

Test Server

For T-Rex PC104 Stack

http://sbc.winsystems.com/products/EPX-GX500.cfm

AMD Geode 500Mhz (1W)

Intel 82551 ethernet (e100) device, not autoprobed by debian installer

Installed using net-install debian 4.0r3 and mirror with standard (not desktop like build server).

Note: there were several DVD read failures on the DVD media during the install which thru re-run (retry) in the installer were worked around.

Generating Java proxy classes from .idl
idlj -td /idlj InsIF.idl
com.sun.tools.corba.se.idl.InvalidArgument: Invalid argument: -td.

Compiler Usage:

java com.sun.tools.corba.se.idl.toJavaPortable.Compile [options] <idl file>

where <idl file> is the name of a file containing IDL definitions, and
[options] is any combination of the options listed below. The options
are optional and may appear in any order; <idl file> is required and
must appear last.

T-Rex CheatSheet

Directory structure :

For compiling/executing correctly TREX expects the following directory structure
<path>
auv-shared
auv-linux
auv (note: this is the auv-qnx directory and may be deprecated in the near future)
Europa
Europa/PLASMA
TREX
We will assume on the rest of the document that this structure is respected.

svn+ssh://

Initializing TREX environment variables:

The file <path>/TREX/devConfig should initialize the environment variable correctly for bash. To load it do the following :
% cd <path>/TREX (note: devConfig script need to be launched from this directory)
% export HAS_AUV_LINUX=yes (note: do not define that if auv-linux is not compiled on your platform - e.g. Mac OS)
% source devConfig
% export VARIANTS=OPTIMIZED (note: to indicate to jam to compile in optimized mode ... so far debug mode is kind of broken as Europa is too strong in some of its assert)
After that you should be able to compile the different component. If HAS_AUV_LINUX is set to yes make sure that auv-linux is correctly compiled and up to date. Then you need to compile Europa :
% cd $PLASMA_HOME
% jam && jam (note: it is better to run it twice to make sure that the binary dependencies are taken care of)
The compilation of TREX core libraries is done similarly
% cd $TREX_HOME
% jam
after that you can compile the binaries amc and sim
% cd ctd2007
% jam amc
% jam sim
amc is the batch command that execute the model without any terminal interaction. sim is a debug interface that can be used to step the agent execution using a limited set of commands through the terminal.
There's also a MonteCarlo sampler used for nightly build to exercise the model but we won't develop it here for now.

Using TREX
TREX configuration files :
On $TREX_HOME/ctd2007 you can find a bunch of .cfg files. They are used by TREX to confiugure itself for the mission a non exhaustive description follow :
amc*.cfg: files defining the number and types of reactors used for the agent. By default the file used is amc.cfg (which is a copy of amc.sim.cfg) and its content on svn should not be modified (it may break the nightly builds). But locally you can replace the file by whichever correspond to your need. Description follow:
amc.sim.cfg: self contained simulation. The VCS is simulated vi a reactor exploiting the model given in simulator.nddl
amc.vcs.cfg: connection to QNX. TREX connect to vcsServer and statePublisher remotely to execute the mission. Basic configuration for these connections is given by vcs.cfg
amc.vcs.new.cfg: new implementation used for linux connection. This configuration will probably replace the amc.vcs.cfg in the near future. It also uses vcs.cfg to connect to the auv components.
amc.play.cfg: used to replay a mission for debugging purpose.
amc.vcs.dl.cfg: add an extra reactor that use CORBA to connect to an Iridum modem. This is used for mixed initiative. This current version is connecting to the modem driver from auv-linux while connecting to vcsServer and statPublisher from QNX. This connection to iridium modem allows TREX to send messages to the shore while possibly integrating new goals coming from there. For testing purpose we have also amc.sim.dl.cfg that allows to connect to this modem without needing a connection to other auv components.
vcs.cfg: indicates the IP and port ussed for connecting to the vehicle. Its content should be :

remoteName should be the URL of the machine where the vcsServer is running. remotePort should have the same value as PORT in $AUV_CONFIG_DIR/vcsServer.cfg. localPort should have the same value as AMC_PORT in $AUV_CONFIG_DIR/statePublisher.cfg (check also in this file that AMC_IP points to the machine where TREX will run).
init.cfg: is the initial plan sent to vcsServer check that the safety behaviors are consistent with the environment and TREX goals (e.g if the depth envelope is too shallow while TREX wants to do a yoyo with a high lower depth).
Debug.cfg: used to activate/deactivate debug messages in $TREX_LOG_DIR/latest/Debug.log. by default it as the same content as Debug.Off.cfg you can replace it by Debug.On.cfg but be aware that TREX is very verbose in this case (implying a huge slow down) and it should not be used except when running sim binary which allows to unload/load this file on demand.
*.solver.cfg: Europa configuration to tweak the plan solver for the given reactor.
*.synch.cfg: Used to configure Europa during synchronization phase of TREX but it is deprecated now and will probably disappear as sson as I have checked that they are not used anymore.
other cfg files: These are the files defining the agent design for each missions. You will find normally correspondings *.exec.nddl *.skipper.nddl *.sim.nddl which describe the model instance for these missions (for example in science.x.skipper.nddl you will see the definition of a VolumeSurvey Goal).These configutrations files will be referred in the future as <mission>.cfg

Note on AUV configuration files useful for simulation :

all these files should be on $AUV_CONFIG_DIR
Make sure that latitude and longitude on workSite.cfg is close enough to the point where TREX expect to do the mission. Otherwise TREX will detect that it is too far from this point and simply do nothing.
Similarly on simulator.cfg check that the depths are reflecting what you would roughly expect at the place where the mission should be executed. These depths are provided by the config attributes depthn with n an integer.
Check statePublisher.cfg and vcssServer.cfg ass described on vcs.cfg item in previous section.
On QNX verify that devices.cfg starts the correct processes including statePublisher
On Linux check the *processes.cfg to see if it starts correct processes including statePublisher
Starting AUV code for TREX
This is required only if TREX expect a connection with the vehicle otherwise you can go directly to the next section.
On QNX
% cd $AUV_HOME/altex/onboard/bin
% ./vcsServer [-v] [-sim]
note:
-v fro being verbose
-sim when in simulation (ie not HW in the loop)

On Linux
% cd $AUV_HOME/onboard/sampleConfig
% ../bin/vcsServer -proc <proc>.cfg [-fastsim]
note:
-proc <proc>.cfg specifies the file where extra processes to start can be found (fastSimprocesses.cfg is for example the processess for fast simulation)
-fastsim indicates to vcsServer that it will run into linux fast simulation
You can change how verbose auv-linux will be by editing log4cxx.cfg
Starting TREX in batch mode
% cd $TREX_HOME/ctd2007
% ./amc_o_rt <mission>.cfg [-fast|-sim] [<nstep>]
note:
the argument order is fixed
-fast indicates that the clock used would connect to auv-linux fast simulation clock
-sim indicates that TREX will just use a clock that is going as fast as TREX can (useful on TREX pseudo amc.sim or on amc.play)
<nstep> indicates how much step TREX is allowed to do for deliberation at least on each tick when on -fast or -sim mode.
You can see TREX activity by looking on $TREX_LOG_DIR/latest/TREX.log
% cd $TREX_LOG_DIR
% tail -F latest/TREX.log

Starting TREX in interactive mode
% cd $TREX_HOME
% sim_o_rt <mission> [-sim|-fast] [<nstep>]
Options:
Q :- Quit
N :- Next
G :- Goto <tick> e.g. g100
R :- Reload Debug.cfg
+ :- enable pattern e.g. '+Agent'
- :- disable pattern e.g. '-Agent'
! :- disable all debug messages
>

You can see here that the command is quite similar to amc except that it exepect the name of the <mission> instead of <mission>.cfg.
You have then an interactive limited shell a la gdb where you can adnvance to a specific tick (g), step to next tick , etc commands R/+/-/! are used to manipulate how much data you want on the Debug.log starting from now.

Comments:

auv-linux uses kernel "real-time" message queues to communicate between some if its internal processes. These kernel object persist between runs (until reboot). Flushing old data out of these queues at start up will fail if the message size has changed. Therefore, it is good practice to manually remove the queues after building auv-linux if there is a chance the these message formats have changed since the last run. To do this, you'll need to first mount a special filesystem that affords access to kernel queues, if no already mounted:

# mkdir /dev/mqueue #by convention, this is the mount point
# mount -t mqueue none /dev/mqueue

Then, remove the queues with this command (as a normal user, not root, for safety):

$ rm /dev/mqueue/*

And save yourself hours of frustration

Posted by brent at Jan 21, 2010 23:06

Document generated by Confluence on Feb 04, 2026 08:05